home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 2 / ETO Development Tools 2.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0068-Docs and Obj pascal-Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  2.2 KB  |  51 lines  |  [TEXT/GEOL]
  1. Item    0108532                         22-June-89        10:12
  2.  
  3. From:   D2086                           Efficient Field Svc, C Faith, PRT
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    Docs and Obj pascal
  8.  
  9. Larry, Keith and Jeff,
  10.  
  11. I had thought of using another method which is why I asked the questions about
  12. the efficiency of the intra-Object calls.  I think Larry's suggestion about
  13. having the subclass OVERRIDE the method that is called rather than calling the
  14. method of the abstract class is exactly what I want.
  15.  
  16. I does look like it would be far more efficient than checking to see where the
  17. call originated manually.
  18.  
  19. As far as Tdocument,  Here is a scenario:
  20.  
  21. I have a TDatabase document that I want to be able to handle creation of any of
  22. its windows.  Only one TDatabase document is allowed to be open at any time.  I
  23. want to be able to have other documents (letters for example) open as well.
  24. Currently If I have all the menu commands handled by the TDatabase I lose
  25. control when another document window is at front.  Say I have one list open I
  26. want to get another up.  I close the list window.  Now since there was a letter
  27. open already that letter document gains control.  I cannot open the new list.
  28. (Not without jumping through hoops).
  29.  
  30. I realize that just setting the target to the document does not solve the
  31. situation.  One must be able to have a document always gain access to commands.
  32.  I agree this can be dangerous.  But under the scenario I described I don't
  33. think any user interface standards would be violated by having the menus
  34. enabled when the letter document is at front.  Having to click on a window of
  35. the TDatabase object to gain access to those commands is entirely too modal and
  36. messy.  And from context none of the menu commands apply to the letter
  37. document, so the user would not be confused by having them active.  Having the
  38. application do everything is also too messy.
  39.  
  40. The ability to have a windowless document is not a must.  I think there is
  41. considerable merit to Larry's suggestion that it would be nice for the user to
  42. have some clue that a document is indeed open.  I do think this should be up to
  43. the programmer however, especially since it would be relatively easy to
  44. implement.
  45.  
  46. regards,
  47.  
  48. Curtis Faith
  49.  
  50.  
  51.